Enterprises have a variety of reasons for wanting to migrate their databases from one database system to another, including reducing license fee costs, simplifying heterogeneous architectures, or taking advantage of new technologies. Currently, most of the major commercial database vendors, including Greenplum® (Pivotal Inc., San Mateo, Calif.), Oracle® (Oracle Corporation, Redwood City, Calif.), SQL Server® (Microsoft Corporation, Redmond, Wash.) and DB2® (IBM Corporation, Armonk, N.Y.), all provide tools that facilitate migrating databases stored in other database systems into their own systems.
The conventional procedure for database migration is to map each of the source database objects, such as tables, views, stored procedures, user-defined functions and triggers, into a direct or indirect equivalent of the migrated database in the new system. In other words, the conventional database migration to a large extent renders the migrated database retaining both logical schema design and physical design of the source database. The logical schema design indicates how the data are grouped into tables and columns, as well as the relationship between tables. The physical design specifies the physical configuration of the database on the storage media, which includes, for example, how to create and maintain indexes, how to do data partitioning, how to distribute data over cluster nodes, how to apply replication, etc. While the logical schema design is visible to the applications developed atop the database (upper applications), the physical design is transparent to the upper applications yet has a significant impact on the performance of such applications.
Most of time, in order to make database applications transparent to the migration, users do not want to change the logical schema design of the migrated database. However, due to the potentially heterogeneous architecture of the new database system, the existing physical design of the source database, although usually optimal at the original database system, may turn out to be suboptimal for the migrated database in the new system and thus incur significant performance degradation. In this case, for the sake of performance optimality, the new database system, after migration, needs to derive a new optimal physical design for the migrated database, and then conducts in-place reconfiguration of its physical layout accordingly.